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Abstract 


Distributed  systems,  now  crucial  to  the  infrastructure  of  our  nation,  are  difficult  to 
understand  and  design.  The  most  effective  way  to  gain  intellectual  control  over  com¬ 
plexity  has  always  been  abstraction.  ATC-NY  and  Cornell  University  have  developed 
the  event  logie  formalism  to  permit  development  of  distributed  systems  at  a  high  level 
of  abstraction.  It  provides  an  implementation-independent  way  to  describe  distributed 
computation  and  system  requirements. 

This  report  describes  the  design  of  an  Event  Logic  Assistant  (Elan)  that  provides 
powerful  automated  support  for  applying  event  logic  to  the  design  and  implementation 
of  high- assurance  distributed  protocols.  Its  guiding  principle  is  that  the  developer 
should  perform  all  creative  work — formalizing  requirements  and  designing  algorithms — 
at  the  highest  possible  level  of  abstraction,  while  automated  tools  take  care  of  the  rest. 

Elan  factors  the  problem  straightforwardly:  capture  a  high-level  description  of  re¬ 
quirements  in  event  logic;  refine  those  requirements  to  a  distributed  algorithm  de¬ 
scribed  in  a  notation  for  “event  logic  programming”;  generate  code  from  E^. 
We  present  a  detailed  outline  of  E^  and  its  semantics,  identify  the  principal  issues  in 
type  checking  and  compilation,  and  describe  enhancement  we  have  made  to  the  NuPrl 
theorem-proving  environment  to  support  interactive  proofs  that  E^  programs  meet 
their  high-level  specifications. 
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1  Introduction 


Both  military  and  commercial  distributed  systems  require  complex  protocols  that  must  be¬ 
have  as  intended  in  all  scenarios.  Such  systems  have  become  too  complex  to  understand, 
develop,  and  maintain  without  mathematical  techniques  and  automated  tools  that  support 
them.  The  most  successful  means  for  handling  complexity  has  always  been  abstraction.  In 
the  past  several  years,  ATC-NY  and  Cornell  University  have  developed  the  event  logic  for¬ 
malism  to  permit  development  of  distributed  systems  at  a  very  high  level  of  abstraction.  It 
provides  an  implementation-independent  way  to  describe  distributed  computation  and  sys¬ 
tem  requirements,  and  can  be  thought  of  as  a  formal  semantic  model  of  message  sequence 
charts. 

This  report  describes  Phase  I  research  on  developing  an  Event  Logic  Assistant  (Elan) 
that  provides  powerful  automated  support  for  applying  event  logic  to  the  design  and  im¬ 
plementation  of  highly  reliable  distributed  protocols.  The  initial  design  of  Elan  factored 
development  into  three  steps: 

1.  Formalize  the  requirements  in  a  high-level  abstract  model  called  event  logic  (sec¬ 
tion  2.1). 

Event  logic  specihcations,  a  formalized  version  of  message  sequence  diagrams,  are  easy 
to  understand. 

2.  Rehne  the  specihcations  to  abstract  information  flow  constraints  (section  2.2). 

The  constraints,  also  expressed  in  event  logic,  provide  an  abstract,  machine-independent 
description  of  a  distributed  algorithm.  NuPrl  can  be  used,  interactively,  to  prove  that 
the  constraints  imply  the  formal  high-level  requirements.  Section  3  describes  enhance¬ 
ments  to  NuPrl  in  support  of  this. 

An  abstract,  machine-independent  description  of  a  distributed  algorithm  will  allow  us 
to  provide  interfaces  to  a  variety  of  tools,  such  as  model  checkers  and  SAT-solvers,  that 
can  be  used  to  verify  properties  of  the  algorithm. 

Previous  work  on  event  logic  developed  an  interface  to  the  ZChaff  SAT-solver  and  used 
it  to  prove  example  lemmas  about  event  logic.  We  have  not  pursued  this  connection 
in  Elan  Phase  I,  but  Elan  Phase  II  will  provide  interfaces  to  such  tools. 

3.  Solve  the  constraints. 

Solving  the  information  how  constraints  amounts  to  deriving  a  program  that  imple¬ 
ments  them.  One  way  to  do  so  is  to  derive  a  message  automaton  that  realizes  the 
constraints  and  apply  tools  that  we  have  already  prototyped  for  generating  code  from 
an  automaton.  Message  automata  are  described  in  section  2.1.2. 
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A  key  result  of  this  research  has  been  to  refactor  the  problem,  for  reasons  described  in 
section  2.3.  Instead  of  rehning  to  information  flow  constraints  and  solving  the  constraints,  we 
rehne  to  programs” — which  provide  a  highly  structured  way  of  describing  information 

flow  constraints.  This  structure  provides  a  much  clearer  path  for  automating  the  process  of 
solving  constraints,  which  is  equivalent  to  compiling 

At  this  stage,  E*  is  a  proposal,  not  a  language.  Section  4  provides  a  detailed  outline  of 
E"^  and  section  5  identihes  the  principal  issues  in  typechecking  and  compiling  it. 

Section  6  summarizes  the  results  and  briefly  describes  their  signihcance  as  a  basis  for 
Phase  II  research. 


2  Background 

2.1  Event  logic 

2.1.1  Event  structures 

Intuitively,  an  event  structure  is  an  abstract  algebraic  construct  that  represents  one  possible 
execution  history  of  a  distributed  system.  An  event  logic  specification  of  a  system  is  a  logical 
proposition  about  event  structures:  it  asserts  that  all  execution  histories  of  the  system  satisfy 
the  proposition. 

Event  structures  can  be  thought  of  as  a  formal  and  general  representation  of  message 
sequence  charts,  a  common  way  in  which  developers  represent  distributed  systems.  The 
execution  of  a  distributed  system  is  characterized  by  a  collection  of  events.  Each  event  e 
occurs  at  a  unique  location,  denoted  e.  A  location  is  an  abstraction  of  an  agent  or  a  process. 

We  can  dehne  these  notions  formally  as  follows.  An  event  language  is  a  multi-sorted 
language  containing  the  following  symbols: 

•  a  sort  E  of  events 

•  a  sort  Loc  of  locations 

•  a  relation  <c  on  events  (the  causal  order  relation). 

•  a  function  ^  :  E  ^  Loc 

We  call  this  set  of  symbols  the  high-level  core  of  event  logic.  An  event  language  may  contain 
other  symbols. 

An  event  structure  is  an  interpretation  of  an  event  language  such  that 

1.  The  relation  <c  is  a  well-founded,  transitive  order  on  E,  called  causal  order 

2.  Restricted  to  the  events  at  any  single  location,  <c  is  a  total  order. 

(We  write  e'  <ioc  e  when  e'  =  e  and  e'  <c  e). 
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2.1.2  Message  automata 

Event  structures  are  very  abstract.  We  need  a  way  to  relate  them  to  actual  programs.  In 
previous  work  we  developed  one  way  to  do  that,  in  terms  of  message  automata. 

We  dehne  an  event  language  S  that  contains  additional  concepts  such  as:  communication 
links,  the  sending  and  receiving  of  messages  on  named  links,  local  state  variables,  and  a  way 
of  labeling  events  with  “kinds.” 

A  message  automaton  is  an  abstract  program  expressed  in  these  terms.  Each  message 
automaton  consists  of  a  hnite  number  of  clauses,  such  as 

•  when  an  event  of  kind  k  occurs,  send  the  contents  of  local  variable  x  on  link  / 

•  when  an  event  of  kind  k  occurs,  set  local  variable  x  to  false 

•  the  only  events  that  affect  local  variable  x  are  events  of  kinds  k,  k' 

We  dehne  the  semantics  of  message  automata^  by  dehning  a  relation  Consistent{es,  M) 
saying,  intuitively,  that  event  structure  es  is  consistent  with  some  execution  of  M .  An 
automaton  is  feasible  if  at  least  one  event  structure  is  consistent  with  it  (i.e.,  M  is  internally 
consistent). 

Recall  that  an  event  logic  specihcation  is  a  logical  proposition  about  event  structures. 
An  automaton  M  realizes  a  specihcation  if  M  is  feasible  and  if  every  event  structure 
consistent  with  M  satishes  fj.  Formally, 

M  realizes  3es.  C onsi stent  {es,  M)  A  Ves.  C onsi stent  {es,  M)  ^ 

An  event  logic  specihcation  ijj  E  L  is  realizable  (written  realizable ('^))  ih 

3M.  M  realizes  ^jJ 

A  constructive  proof  of  realizable('^)  provides  a  realizer;  and  in  previous  work  we  have 
implemented  a  translator  that  synthesizes  Java  code  from  message  automata.  Thus,  synthesis 
of  correct-by-construction  code  for  specihcation  ip  is  reduced  to  proving  realizable('^).  We 
have  developed  a  number  of  tactics  to  help  carry  out  these  proofs  interactively  in  NuPrl. 

2.2  Information  flow  constraints 

The  logical  picture  described  in  sections  2.1  and  2.1.2  is  unstructured.  It  provides  no  method 
for  proceeding  from  the  specihcation  to  a  message  automaton  that  realizes  it.  We  developed  a 
more  disciplined  method — factor  the  argument  through  an  intermediate  stage  that  abstracts 
the  algorithmic  core  as  abstraet  information  flow  constraints,  leaving  two  verihcation  tasks: 

^The  example  shows  instances  of  three  of  the  six  basic  clauses  used  to  defined  message  automata. 
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•  Prove  that  the  information  flow  constraints  imply  the  original  requirements. 

This  step  is  carried  out  interactively  in  NuPrl.  In  Phase  I  we  have  improved  the 
automated  support  for  this  step  by  adding  congruence  closure  techniques  to  NuPrl 
(section  3). 

•  Solve  the  constraints. 

We  showed  how  to  compile  information  flow  constraints  that  take  the  special  form  of 
information  flow  on  a  graph.  We  can  compile  constraints  expressed  in  this  special  form 
by  extracting  a  message  automaton  and  applying  tools  developed  in  previous  work  to 
generate  Java  code  from  the  automaton. 

Our  method  for  describing  an  algorithm  abstractly  is  to  dehne  an  event  class  that  provides 
a  view  of  the  relevant  system  events  and  a  characterization  of  certain  causal  relations  among 
them. 

2.2.1  Event  classes 

An  event  class  consists  of  a  set  of  events  and  a  map  that  associates  information  (a  value  in 
some  specihed  type)  with  each  of  them.  If  V  is  an  event  class  we  let 

•  E(y)  denote  its  associated  set  of  events 

•  V{e)  denote  the  information  associated  with  an  event  e  G  E{V) 

The  interface  to  a  component  is  an  important  example  of  an  event  class.  Its  events  are 
the  events  occurring  at  the  interface;  typically,  the  associated  information  consists  of  the 
input  and  output  values  communicated  by  those  events. 

2.2.2  Antecedent  fnnctions 

For  any  event  class  V,  an  antecedent  funetion  on  E  is  a  function  /  :  E(y)  E(y)  such 
that,  for  any  event  e  G  E(y),  /(e)  is  causally  before  or  equal  to  e — i.e.,  /(e)  <c  e. 

Intuitively,  the  information  available  at  event  e  must  come  either  locally,  from  prior  events 
at  the  same  location  as  e,  or  externally  from  an  event  at  some  other  location.  In  describing 
an  algorithm  abstractly,  we  use  /(e)  (where  /  is  an  antecedent  function)  to  indicate  the 
source,  if  any,  of  external  information  available  at  e. 

Given  an  antecedent  function  /,  we’ll  say  that 

•  e  is  initial  if  /(e)  =  e 

That  is,  the  information  at  e  does  not  come  from  elsewhere. 

•  e  propagates  if  there’s  some  e'  such  that  /(e')  =  e 
That  is,  some  other  event  e'  gets  information  from  e. 
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2.2.3  Information  flow  constraints 

The  information  flow  constraints  for  an  abstract  algorithm  are  expressed  in  terms  of  an  event 
class  V  and  an  antecedent  function,  /,  on  V.  The  constraints  typically  have  the  following 
form: 

•  Initialization:  If  e  is  initial,  then  P{^,V{e)) 

Property  P,  which  relates  locations  to  values,  must  hold  for  the  location  and  value  of 

every  initial  event. 

•  Propagation:  If  e  is  not  initial,  then  R{e,  f{e),V{e),V{f{e)) 

R  relates  the  location  and  value  of  an  event  to  the  location  and  value  of  its  antecedent. 

•  Termination:  e  propagates  unless  Q(e,V(e)) 

Information  keeps  on  propagating  until  a  certain  stopping  condition  Q  holds. 

2.3  Lessons  learned 

The  results  of  section  2.2  leave  us  with  the  problem  of  transforming — automatically,  if 
possible — more  general  information  flow  constraints  into  information  flows  on  a  graph. 

Our  original  hypothesis  was  that  a  collection  of  heuristic  transformation  techniques  could 
be  developed  that  would  apply  to  typical  information  flow  constraints  to  transform  them  into 
an  information  flow  on  a  graph.  We  tested  our  hypothesis  on  the  information  flow  constraints 
for  a  simple  algorithm  for  leader  eleetion  in  a  ring.  Even  for  this  relatively  simple  algorithm, 
we  found  that  the  generic  methods  that  we  had  envisioned  were  not  practical. 

The  problem  was  that  the  abstract  constraints  can  refer  to  the  entire  past  history  of 
events,  but  an  efficient  algorithm  must  remember  only  a  small  part  of  that  history  or  be 
able  to  accumulate  a  small  “compression”  of  that  history.  We  had  hypothesized  that  we 
could  automatically  synthesize,  from  the  logical  form  of  the  information  flow  constraints,  an 
efficient  compression  function  on  the  history. 

Working  on  this  hypothesis  we  developed  an  initial  concept  of  a  programmable  class  in 
which  the  value  of  an  event  in  the  class  is  a  function  of  the  full  history  of  values  of  prior 
events  in  the  class.  We  built  a  prototype  compiler  that  attempted  to  optimize  the  function 
with  which  the  class  recognizes  and  assigns  values  to  an  event.  The  goal  of  this  optimization 
was  to  replace  the  dependence  on  the  full  history  by  a  dependence  on  something  smaller. 
The  method  used  in  the  prototype  was  based  on  recognizing  certain  functions  of  the  full 
history  of  values  that  could  be  rewritten  into  equivalent  functions  expressed  in  terms  of  an 
accumulator.  The  algorithm  then  tried  to  combine  the  accumulators  for  the  subexpressions 
into  one  global  accumulator  for  the  entire  class. 
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The  lesson  learned  from  this  exercise  was  that  for  the  classes  that  occurred  even  in  our 
relatively  simple  leader  election  algorithm,  the  method  based  on  rewriting  would  not  suffice. 
It  did  not  succeed  in  hnding  an  accumulator  that  efficiently  compressed  the  state  information 
needed  by  the  program. 

Analyzing  the  reasons  for  this  failure,  we  saw  that  more  structure  would  be  required  for 
event  classes  to  be  efficiently  programmed.  This  analysis  led  to  the  development  of  an 
abstract  language  for  programming  in  event  logic. 

2.4  Overview  of 

is  a  flexible,  extensible  notation  for  “programming”  in  event  logic,  from  which  it  will  be 
possible  to  generate  efficient  code. 

2.4.1  E*  programs 

An  E*  program  consists  of  two  things:  a  collection  of  programmable  event  classes  and  a 
collection  of  propagation  rules  and  propagation  constraints. 

Programmable  event  class  An  event  class  is  programmable  if  local  information  suffices 
to  determine  whether  an  event  belongs  to  the  class  and  to  compute  its  value. 

Propagation  rules  and  constraints  A  propagation  rule  specihes  how  events  in  certain 
event  classes  cause  events  in  other  classes.  A  propagation  constraint  specihes  that  events  in 
some  event  class  can  only  be  caused  by  events  in  certain  others. 

Semantics  As  explained  in  section  2.1,  we  formalize  an  execution  history  of  a  distributed 
system  as  an  event  structure — a  collection  of  events  together  with  the  causal  relations  be¬ 
tween  them.  With  each  E"^  program  we  associate  a  predicate  that  dehnes  a  set  of  event 
structures — all  possible  executions  consistent  with  the  requirements  of  the  program.  Thus, 
verihcation  that  an  E"^  program  meets  some  high-level  requirement  will  be  purely  an  exercise 
in  logic. 

Language  A  few  basic  propagation  rules  and  event  classes,  together  with  a  few  basic  com- 
binators  for  combining  them,  will  generate  a  rich  collection  of  programs.  The  straightforward 
logical  semantics  makes  it  easy  to  extend  E"^  by  adding  sophisticated  constructs  dehned  in 
terms  of  the  basics. 
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2.4.2  Generating  code  from  programs 

We  can  naturally  associate  an  implicit  “local  state”  with  every  event:  it  records  the  values 
associated  with  all  causally  prior  events.  Any  program  will  straightforwardly  correspond 
to  a  collection  of  communicating  state  machines  that  maintain  this  natural  local  state — 
essentially,  each  machine  transmits  all  the  information  it  has  and  saves  all  the  information 
it  receives. 

It  will  not  be  practical  to  implement  such  state  machines  as-is.  A  program  with  an 
efficient  implementation  must  eventually  “forget”  the  values  of  prior  events.  The  structure 
of  a  programmable  event  class  makes  this  forgetting  explicit  and  allows  a  code  generator  to 
limit  the  amount  of  information  needed  to  recognize  and  respond  to  new  events. 

3  Congruence  closure 

3.1  The  basic  algorithm 

One  of  the  fundamental  forms  of  reasoning  is  equality  reasoning — which  proceeds  by  “sub¬ 
stituting  equals  for  equals.”  For  example,  from  the  assumptions 

1.  a  =  h 

2.  b  =  c 

3.  f{a,  c)  =  X 
A.  X  <  y 

it  follows  that  f{c,  c)  <  y:  by  (1)  and  (2),  a  =  c;  substituting  that  into  (3)  gives  /(c,  c)  =  x; 
and  substituting  that  into  (4)  gives  /(c,  c)  <  y. 

Two  expressions  built  from  function  symbols  and  atoms  (constants  or  variables)  are 
equivalent,  under  given  hypotheses,  if  they  can  be  proven  equal  from  those  hypotheses  by 
applying  substitutions  of  equals  for  equals.  A  congruence  closure  algorithm  builds  a  data 
structure  that  keeps  track  of  those  equivalence  classes.  Given  the  hypotheses  in  the  example, 
the  expressions  /(c,  c)  and  x  will  be  equivalent,  so  will  belong  to  the  same  equivalence  class. 
Once  that  data  structure  has  been  built,  answering  the  question  “are  expressions  ti  and  t2 
equivalent?”  becomes  extremely  efficient. 

Many  congruence  closure  algorithms  are  known,  but  exploiting  them  in  NuPrl  presents 
two  difficulties: 

•  To  produce  a  complete  NuPrl  proof  we  cannot  simply  accept  an  assurance  from  some 
external  oracle  that  two  terms  are  equal  but  must  actually  construct  a  NuPrl  proof 
that  they  are  equal. 
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•  The  proofs  produced  by  congruence  closure  algorithms  are  untyped,  but  NuPrl  is  a  type 
system  and  equality  of  terms  is  meaningful  only  with  respect  to  a  type  assignment. 

The  algorithm  described  in  [39]  generates  a  congruence  closure  data  structure  in  such 
a  way  that  one  can  extract  for  any  pair  of  equivalent  expressions  a  direct  proof  that  they 
are  equal.  We  adapted  this  algorithm  by  coding  it  into  the  Lisp  core  services  of  NuPrl 
and  dehning  tactics  that  treat  the  proof  produced  by  the  congruence  closure  algorithm  as 
a  “proof  plan.”  Tactics  that  use  congruences  apply  type  inference  algorithms  (already  part 
of  NuPrl  tactics)  to  £11  in  the  types  in  that  plan.  If  this  succeeds  in  creating  a  valid  NuPrl 
proof,  proof  of  the  goal  can  be  completed  automatically. 

3.2  Matching  modulo  a  congruence 

We  have  extended  our  tactics  to  include  matching  modulo  congruence.  Here  is  an  example, 
showing  how  the  conclusion  P{x,  y)  is  automatically  derived  from  the  hypotheses 

1.  \/z.  Q(z)  =>  P(z,f(z)) 

2.  y  =  f{x) 

3.  Q{x) 

The  tactic  tries  to  match  the  conclusion  P{x,y)  against  (appropriate  subterms  of)  the 
hypotheses  modulo  the  congruence.  In  this  case,  because  f{x)  and  y  are  equivalent,  P{x,y) 
matches  the  subterm  P{z,f{z))  under  the  substitution  of  x  for  2:.  Using  that  match,  and 
hypothesis  (1),  proving  the  conclusion  reduces  to  proving  Q{x);  but  Q{x)  is  hypothesis  (3). 

3.3  Heuristics 

We  have  implemented  a  general  method  for  specifying  heuristics  that  add  to  the  hypotheses 
equations  that  we  know  to  be  true.  An  equational  heuristic  consists  of  a  pattern  and  a  collec¬ 
tion  of  equations.  Whenever  some  subterm  of  the  goal  matches  the  pattern,  a  corresponding 
instance  of  each  equation  will  be  added  to  the  hypotheses.  Applying  equational  heuristics  is 
logically  sound,  because  any  time  one  of  the  added  equations  is  used  in  a  proof,  NuPrl  will 
require  that  it  be  proven  true. 

Here  are  some  simple  but  useful  equational  heuristics: 

•  The  pattern  is  if  x  then  y  else  and  the  equations  are  (if  true  then  y  else  z)  =  y 
and  (if  false  then  y  else  z)  =  z 

•  The  pattern  is  x  Sz  y  and  the  equations  are  (true  ^  y)  =  y  and  {x  &  true)  =  x 


Similar  equational  heuristics  add  knowledge  about  standard  operations  on  pairs  and  lists. 
We  also  add  domain  specific  knowledge  about  the  logic  of  events,  such  as:  the  location  of 
the  sender  of  a  message  is  the  source  of  the  link  on  which  the  message  is  sent. 

Each  added  equation  is  tagged  with  a  special  token.  When  one  of  these  equations  is 
used,  the  proof  tactic  consults  the  token  to  determine  how  to  prove  it.  (Recall  that  this 
is  obligatory  insurance  against  adding  an  unjustified  hypothesis.)  All  these  improvements 
have  been  added  to  the  Auto  tactic,  which  automates  a  large  body  of  strategies  for  proving 
propositions  about  event  logic. 

3.4  Measurements 

To  obtain  a  rough  measure  of  the  value  of  these  improvements  we  created  a  database  of 
inferences  from  our  large  library  of  NuPrl  proofs.  These  proofs,  some  with  hundreds  of 
individual  inference  steps,  were  created  interactively  by  invoking  tactics  at  each  goal.  A 
tactic  entered  by  the  expert  user  might  have  a  form  like  this: 

By  lemma  xxx  THEN  Auto 

THEN  Instantiate  3  with  [a;b;c] 

THEN  Auto 
THEN  Try  (tael) 

THEN  Try  (tac2) 

A  tactic  of  the  form  A  THEN  B  applies  the  tactic  A  to  the  current  goal  and  generates  a 
list  of  subgoals  and  applies  tactic  B  to  each  of  these  subgoals.  To  create  our  database  we 
divided  complex  tactics  into  their  constituent  parts  so  that  we  had  all  of  the  subgoals  for 
each  individual  tactic  A,  B,  etc. 

In  our  database,  a  node  consists  of  a  subgoal  and  an  individual  simple  tactic.  We  call  a 
subgoal  that  was  completed  by  its  tactic  a  leaf  node  and  a  subgoal  and  tactic  that  generated 
further  subgoals  an  interior  node.  From  4206  complete  NuPrl  proofs  we  created  a  database 
of  203,455  nodes — 75,919  interior  nodes  and  127,536  leaves. 

We  expected  that  most  of  these  leaf  nodes  were  already  completed  by  the  old  Auto  tactic, 
so  we  were  particularly  interested  in  how  many  of  the  interior  nodes  of  our  old  proofs  could 
now  be  completed  automatically  by  an  improved  Auto  tactic  that  used  congruence  closure. 
There  were  6685  such  cases,  in  some  of  which  the  new  Auto  replaced  many  steps  of  the 
original  proof. 

By  that  rough  measure,  the  extended  congruence  closure  algorithm  has  automated  about 
10%  of  what  had  been  previously  been  done  interactively.  We  believe  that  there  is  still  room 
for  improvement  in  this  general  purpose  algorithm. 
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4  E^:  Programming  in  event  logic 

This  section  outlines  E^.  An  program  defines  a  system  in  terms  of  events  and  their 
causal  relations:  Execution  consists  of  recognizing  events  and  acting  on  them,  causing  other 
events  to  happen. 

Accordingly,  an  E*  program  consists  of  event  classes  and  propagation  rules.  Intuitively, 
an  event  class  recognizes  some  set  of  events  and  assigns  information  to  each  event  it  recog¬ 
nizes.  A  propagation  rule  stipulates  that  certain  events  cause  other  events  and  defines  the 
information  propagated.  Reasoning  about  programs  often  requires  propagation  constraints 
expressing  the  assumption  that  certain  events  can  only  be  caused  by  certain  others.  We 
formalize  these  ideas  straightforwardly. 

4.1  Event  class 

An  event  class  of  type  T  is  a  partial  function  from  the  domain  E  of  events  into  T.  For  the 
present  discussion,  T  is  any  type  definable  in  the  NuPrl  environment.  Some  abbreviations: 

•  If  e  is  an  event  and  X  an  event  class. 


X(e)  =  ± 

means  that  e  is  not  in  the  domain  of  X. 

•  Event  e  belongs  to  (is  recognized  by)  X,  written  e  G  X,  if 

A'(e)  ^  ± 

•  If  e  is  an  event  and  X  an  event  class,  we  define  e  G  X[n]  to  mean 

e  G  X  &  X(e)  =  v 

In  words,  e  belongs  to  X  with  value  v.  (Note  that  an  event  may  belong  to  different 
event  classes  and  they  may  assign  it  different  values.) 

•  We  define  v  =  most  recent  A  before  e  |  P{v)  to  mean 

3e'  <ioc  e.  e'  eA  A  v  =  A(e')  A  P{v)  A  Ve"  G  A.  (e'  <ioc  e"  <ioc  e)  =>  ^P(A(e")) 

In  words,  there  is  an  A  event  prior  to  e  with  a  value  satisfying  P,  and  v  is  the  value 
of  the  most  recent  such  event.  If  the  predicate  P  is  always  true,  we  omit  it  and  write 

V  =  most  recent  A  before  e. 
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4.2  Programmable  event  class 

If  an  event  class  is  programmable,  local  information  will  snffice  to  compnte  whether  an  event 
belongs  to  the  class  and,  if  it  does,  to  compnte  its  valne.  The  programmable  classes  will 
be  either  base  classes  or  bnilt  from  base  classes  by  applying  certain  combinators.  is 
extensible  by  dehning  new  combinators  in  terms  of  the  basics.  For  simplicity’s  sake,  this 
section  explains  the  idea  informally,  and  omits  discussion  of  types  and  type  correctness. 

Because  an  efficient  program  cannot  store  a  complete  history  of  all  prior  events,  we  limit 
the  amount  of  local  state  information  a  programmable  class  may  use  to:  the  value  of  the 
most  recent  events  in  a  hxed  set  of  other  classes,  and  the  value  of  the  most  recent  event  in 
its  own  class.  In  theory,  this  is  no  limitation  at  all  because  we  can  dehne  a  programmable 
class  that  accumulates  the  history  of  all  events  that  have  causally  preceded  it.  In  practice, 
however,  this  limitation  will  make  it  possible  to  synthesize  efficient  code  from  typical 
programs — because  programmers  will  not  make  use  of  classes  that  accumulate  unbounded 
amounts  of  information  without  designing  mechanisms  by  which  unneeded  state  information 
can  be  purged. 

Base  classes: 

•  receive(/,t) 

Recognizes  the  arrival  of  messages  on  link  /  with  tag  t — where  link 
of  “port”  and  tag  an  abstraction  of  “header.”  The  value  assigned  to 
the  message  received. 

•  receive(*,t) 

Recognizes  the  arrival  of  messages  on  any  link  with  tag  t. 

•  internal  (name) 

Every  event  internal  to  a  process  has  a  label  (a  generalized,  abstract  program  counter), 
and  this  class  recognizes  the  internal  events  labeled  by  the  given  name.  For  technical 
reasons,^  the  value  it  assigns  to  any  event  is  a  randomly  chosen  integer.  As  will  be 
seen,  we  can  easily  use  the  basic  combinators  to  dehne  a  class  of  internal  events  that 
assigns  a  deterministic  value  to  each  of  its  events. 

•  Var 

We  will  allow  programs  to  contain  variables  that  denote  unspecihed  programmable 
classes.  That  will  allow  us  to  dehne  program  modules  that  are  parameterized  by  some 
as  yet  unspecihed  input  events. 

^To  simplify  the  description  of  protocols  that  rely  on  randomizing  operations. 


is  an  abstraction 
a  receive  event  is 
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Abstract  state  variables: 

We  define  an  operator  '  on  event  classes  so  that  for  any  event  class,  A,  the  class  A' 
recognizes  any  event  for  which  a  strictly  prior  A  event  has  occurred  and  assigns  it  the  value 
of  the  most  recent  such  prior  event.  The  specihcation  of  this  combinator  in  event  logic  is 

e  E  A'[v]  V  =  most  recent  A  before  e 

We  call  classes  of  the  form  A'  abstract  state  variables  because  A'  remembers  the  value  of 
the  most  recent  A  event. 

Basic  combinators: 

Let  A,  B,  C,  D  be  programmable  classes.  Then  the  following  classes  are  also  programmable: 
•  A^ 

Recognizes  A  events.  To  each  e  G  A[v]  assigns  the  pair  (n,t)  where  t  is  the  time  at 
which  e  occurs. 


.  let  X  =  f{A,...,B-C\...,D'-X') 

This  is  the  basic  dehnition  scheme  for  programmable  classes.  It  requires  /  to  be  a 
partial  function  and  says  that 


JT  a  e  ^  a  ...  e  ^  B 

I  f{A{e),...,B{e),C'{e),...,D'{e),X'{e))  otherwise 


The  key  points  are  that  an  event  in  X  must  belong  to  one  of  the  classes  A,...,B] 
and  that  the  criteria  for  membership  in  X  and  the  value  of  an  event  in  X  may  also 
depend  on  the  values  of  some  auxiliary  state  variables  {C', . . . ,  D')  and  the  value  of 
the  previous  X  event  (hence  the  reference  to  X'). 

In  terms  of  these  basic  combinators  we  can  dehne  many  others,  for  example: 

•  A  +  B 

Recognizes  events  that  are  A  events  or  B  events  and  distinguishes  three  cases: 

—  A  but  not  B  (in  which  case,  it  assigns  the  value  assigned  by  A) 

—  B  but  not  A  (in  which  case,  it  assigns  the  value  assigned  by  B) 

—  Both  A  and  B  (in  which  case,  it  assigns  the  pair  of  values  assigned  by  A  and  B) 

This  class  can  be  dehned  by  let  A  +  B  =  f{A,  B)  for  the  appropriate  function  /. 

•  ho  A 

Recognizes  those  e  &  A[v]  such  that  v  G  domain(h)  and  assigns  the  value  h{y). 

This  class  is  dehned  by  let  ho  A  =  h{A). 
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•  A  \  b,  where  6  is  a  predicate 

Recognizes  those  e  &  A[v]  such  that  v  satishes  6;  assigns  the  same  value  as  A. 

This  class  is  dehned  by  let  A\h  =  f{A),  where  /  is  the  partial  identity  function  whose 
domain  consists  of  those  v  that  satisfy  b. 

•  A  or  B 

If  classes  A  and  B  have  the  same  type  T  and  are  disjoint  then  Aor  B  recognizes  events 
that  are  A  events  or  B  and  assigns  the  same  value.  This  class  is  h  o  [A  +  B)  where 
h  :  (T  +  T)  — T  forgets  which  part  of  the  disjoint  union  the  value  comes  from. 

•  accum(/i,  x,  A) 

Recognizes  A  events  and  assigns  to  each  event  e  G  A[no]  the  value  h{vo,  h{vi,  h{. . .  ,x) . . .) 
where  Ui, . . .  are  the  values  of  all  prior  A  events. 

This  class  is  defined  by 

let  accum(h,  x,  A)  =  /(A;  (accum(h,  x,  A))')  where 

/(a,T)  =  X 

fia,z)  =  h{a,z) 


.  A* 

Recognizes  A  events.  To  each  e  G  A{v)  assigns  the  value  {n,v),  where  n  is  the  number 
of  prior  A  events  that  have  occurred  at  e. 

This  class  is  dehned  by  A"^  =  accum(/i,  (0,  T),  A),  where  h{v,  {n,  v'))  =  {n  +  l,v). 

•  A]  B 

Recognizes  any  event  e  E  B  that  is  locally  preceded  by  some  A  event,  li  e  E  B[b],  then 
the  value  assigned  to  e  is  a  pair  (a,  b)  where  a  =  most  recent  A  before  e. 

This  class  is  dehned  by 


let  A;  B 

=  f{B,A;A')  where 

=  T 

=  T 

=  {a,b) 

f{b,±,a') 

=  {a',  b) 

The  basic  classes  and  combinators  (which  we  may  extend  using  the  dehnition  scheme) 
are  sufficient  to  program  all  event  recognition  and  value  computations. 
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4.3  Propagation  rules 

Besides  recognizing  events  and  computing  values,  a  distributed  algorithm  must  act  on  events 
by  propagating  information.  This  aspect  of  the  algorithm  is  described  in  as  a  set  of 
propagation  rules. 

•  start  (name) 

This  is  the  base  case  rule.  It  guarantees  the  creation  of  one  event  of  class  internal(name). 

•  4  ^  receive(/,  f) 

This  is  the  basic  rule  for  message  propagation.  It  says  that  every  A  event  occurring 
at  the  source  of  link  /  results  in  a  receive  event  on  link  I,  having  the  same  value  and 
having  tag  t.  If  we  want  to  transmit  not  the  value  of  each  A  event  but  some  function 
of  that  value,  we  say  ho  A  =>  receive(/,  t). 

•  A  ^mcast  receive  (f) 

This  is  the  multicast  propagation  rule.  It  is  well-formed  only  for  classes  A  with  value 
type  of  the  form  hst(LmA;)  x  T.  If  e  G  A[{lnks,v)]  it  sends  v  on  every  link  in  Inks. 

More  formally,  there  will  be  a  receive  of  v  with  tag  t  at  the  destination  end  of  each 
link  in  Inks',  where 

Inks'  =  {/  G  lnks\src{l)  =  e} 

•  A  ^  internal  (name) 

This  is  the  time-delay  propagation  rule.  It  is  well-formed  only  for  classes  A  with  a 
value  type  that  can  be  interpreted  as  a  time. 

It  says  that  for  each  event  e  G  A[t],  an  internal  event  labeled  name  will  occur  precisely 
t  time  units  later. 

4.4  Semantics  of  propagation  rules 

Each  propagation  rule  has  a  specihcation  in  event  logic.  The  basic  propagation  rule,  multi¬ 
cast,  and  time-delay  all  have  a  similar  form,  asserting  that: 

causally  after  every  e  G  yl[n]-event  there  will  exist  an  e'  G  B[v']  such  that  e  <c  e' 
and  V,  v'  are  appropriately  related. 

For  example,  in  the  basic  propagation  rule,  A  receive(/,  t),  the  base  class  receive(/,  t) 
plays  the  role  of  “i?”  and  equality  is  the  “appropriate  relation”  between  values.  This  propa¬ 
gation  rule  corresponds  to  reliable  message  transmission  on  the  given  link;  so  the  generated 
code  must  implement  it  with  a  reliable  transport  mechanism  such  as  TCP. 
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TCP  connections  also  guarantee  FIFO  message  delivery.  Using  the  <ioc  ordering,  this 
property  is  easily  expressed  in  event  logic.  Our  default  assumption  is  that  a  link  I  implements 
a  reliable  FIFO  channel.  But  will  also  allow  the  programmer  to  declare  that  a  link  / 
is  assumed  to  be  only  reliable  (and  not  assumed  FIFO),  or,  alternatively,  that  link  /  is 
neither  reliable  nor  guarantees  FIFO  ordering  of  messages.  Such  declarations  will  allow  the 
generated  code  to  make  use  of  a  transport  mechanism  such  as  UDP  that  uses  less  bandwidth 
but  provides  weaker  guarantees. 

4.5  Propagation  constraints 

Note  that  the  specihcation,  given  above,  oi  A  ^  B  says  that  there  is  a  mapping  from  A- 
events  into  B-events.  It  says  that  every  4-event  results  in  a  5-event,  but  it  does  not  say 
that  every  5-event  must  be  caused  by  an  4-event. 

To  state  such  converse  requirements,  5^  will  also  include  propagation  constraints  of  the 
form 

4i,  •  •  • ,  4,^  5 

This  constraint,  saying  that  every  5  event  must  be  causally  preceded  by  an  event  in  one  (or 
more)  of  the  4j,  has  the  logical  specihcation 

Ve  G  5.  3e  .  e  e  A  (e  G  A^  V  ...  V  e  G  4^) 

We  may  use  4  5  as  a  shorthand  for  the  propagation  rule  A  ^  B  and  the  propagation 

constraint  A  ^  B. 

4.6  The  semantics  of  a  program 

As  shown  above,  event  classes,  propagation  rules,  and  propagation  constraints  correspond 
to  predicates  on  event  structures.  The  semantics  of  an  5^  program  is  the  conjunction  of  all 
of  them. 

4.7  Examples 

Example  event  class:  counter  events  The  class  that  recognizes  internal  events  labeled 
“count”  and  whose  values  are,  successively,  0,  1,  2,  . . . ,  is  dehnable  as  tti  ointernal(coMnt)^, 
where  tti  is  the  projection  function  that  selects  the  hrst  value  of  an  ordered  pair. 

Example  event  class:  deterministic  internal  events  The  class  that  recognizes  internal 
events  labeled  “zero”  and  always  returns  value  0  is  dehnable  as  g  o  internal(yero),  where  g 
is  the  constant  function  that  returns  0  on  all  inputs. 
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Example:  Perfect  clock  The  program  consisting  of  the  following  two  rules  dehnes  a 
perfect  clock. 

start  (c/oc/c) 

(An.  1)  o  internal (c/oc/c)  -v^  internal (c/oc/c) 

The  propagation  rule  is  the  time-delay  rule,  because  the  right-hand  class  consists  of 
internal  events.  Each  event  has  the  value  1,  which  specihes  that  the  next  event  will  occur 
one  time  unit  later. 

Example:  Dissemination  We  wish  to  design  a  system  with  two  kinds  of  inputs.  The 
hrst  kind  of  input  is  conhguration  data.  Inputs  of  this  kind  at  location  i  will  inform  process 
i  of  a  set  of  links  to  neighbors  with  which  it  should  communicate.  Each  event  in  Nbr,  the 
class  of  conhguration  inputs,  either  adds  or  removes  a  link. 

For  an  appropriate  function  h,  the  current  set  of  neighbors  is  computed  by  the  event  class 

Conhg  =  accnm(h,  0,  Nbr) 

The  second  kind  of  input  is  sensor  data,  represented  by  event  class  Sensor.  The  dissemi¬ 
nation  program  will  send  sensor  data  to  all  current  neighbors  and  also  forward  sensor  data 
it  receives  to  its  neighbors.  In  order  to  control  this  dissemination  process,  the  original  sen¬ 
sor  data  will  be  tagged  with  its  location  and  each  forwarding  process  will  add  its  location 
to  the  set  of  tags.  A  process  will  not  re-forward  information  tagged  with  its  own  location 
(^#  programs  include  an  expression  here  that  evaluates  to  the  location  of  the  evaluating 
process). 

The  dissemination  program  consists  of  the  following  two  propagation  rules 

Config]  Tag  =^mcast  receive (dissem) 

Config]  Fwd  ^mcast  receive (dissem) 
where 

Tag  =  {Xv.{v,  {here}))  o  Sensor 

Fwd  =  (A(n,  <s).(n,  s  U  {here}))  o  (receive(>K,  dissem)  \  (Xp.here  ^  7i2{p))) 

The  hrst  of  these  rules  sends  the  sensor  data,  tagged  with  the  location,  on  all  links  in  the 
most  recent  conhguration.  The  second  rule  forwards  disseminated  sensor  data  that  is  not 
tagged  with  the  current  location  to  all  links  in  the  most  recent  conhguration  after  adding 
the  current  location  to  the  set  of  tags. 

The  program  will  also  contain  the  propagation  constraint 

Tag,  Fwd  <^=  receive(*,  dissem) 

And  we  could  write  the  entire  program  as 

Config]  {Tag  or  Fwd)  ^mcast  receive(dissem) 
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4.8  Defining  extensions  to 

The  event  class  combinators  listed  in  section  4.2  all  have  simple  dehnitions  and  simple  logical 
specihcations.  The  principles  of  allow  new  combinators  to  be  defined  easily.  When  we 
dehne  a  new  combinator  we  will  also  derive  a  logical  specihcation  for  it,  and  anticipate 
dehning  many  combinators  that  express  useful  distributed  programming  patterns. 

Here  is  an  example  of  such  a  pattern;  it  recognizes  receipt  of  a  message  from  a  remote 
site  that  responds  to  an  earlier  (asynchronous)  request;  and  the  value  assigned  is  a  pair 
consisting  of  the  request  and  response  values.  We  can  generalize  this  pattern  to  the  task  of 
recognizing  events  in  a  class  B  for  which  an  earlier  event  in  class  A  has  a  “matching”  value. 
We  could  express  this  pattern  with  a  new  combinator,  where  the  parameter  i?  is  a 

relation  dehning  what  we  mean  by  a  matching  value: 

e  e  {A;jiB)[{a,b)]  e  e  B[b]  A  a  =  most  recent  A  before  e  |  R{a,b) 

But,  there  is  a  problem  with  the  above  specihcation.  As  stated,  the  only  way  to  realize 
it  with  a  programmable  class  is  to  accumulate  the  values  of  all  A-events.  The  reason  is 
that,  without  some  restriction  on  the  relation  R,  we  cannot  be  sure  that  the  value  of  any 
A-event  will  not  match  some  future  H-event  (and  be  the  most  recent  match).  Thus,  we  can 
never  “forget”  the  value  of  any  A-event,  so  we  would  have  to  allow  the  state  to  increase 
unboundedly. 

If  we  change  the  logical  specihcation  so  that  A^rB  recognizes  H-events  for  which  an 
earlier  A-event  has  an  /^-matching  value  which  has  not  also  matched  an  intervening  B -event, 
then  we  can  realize  the  combinator  efficiently.  The  state  will  now  include  only  A-events  that 
have  not  yet  matched  a  H-event.  This  state  could  still  grow  unboundedly,  but  for  typical 
applications  it  would  not.  (To  guarantee  that  the  states  is  bounded,  we  could  make  a  variant 
that  stores  at  most  N  unmatched  A-events.) 

If  we  dehne  R'{e,  a,  b)  to  be 

R{a,  b)  A  Ve'  G  B.  e'  <ioc  e  -^R{a,  B{e')) 
then  the  new  specihcation  of  A^rB  is 

ee(A  ■,RB)[{a,b)]  e  G  i?[6]  A  a  =  most  recent  A  before  e  |  R'{e,a,b) 

since  R'{e,a,b)  says  that  a  is  a  match  to  b  that  has  not  been  matched  by  an  intervening 
H-event. 

To  implement  this  we  dehne  a  programmable  event  class  that  accumulates  the  values  of 
unmatched  A-events. 

Unmatched{A,  B,  R)  =  accum(h,  nil,  B  A)  where 
h{a,L)  =  append  (a,  L) 
h{b,L)  =  L  -  {a' \  R{a' ,b)} 
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Then,  using  the  dehnition  scheme,  we  can  dehne  A]  RBhj 

A;r  B  =  f{B,  ( Unmatched{A,  B,  R))') 

for  a  suitable  function  /.  The  function  /  must  be  undehned  unless  there  is  an  unmatched 
prior  yl-value  that  matches  the  5-value.  So  /  is  dehned  by: 

f{b,R)  =  T 

/(6,  U)  =  (a,  6),  if  a  =  last  a'  &  U  s.t.  R{a\b) 
f{b,  U)  =  ±,  otherwise 

We  must  prove  that  the  logical  specihcations  of  our  dehnitions  imply  the  desired  logical 
specihcation  for  the  new  combinator.  We  anticipate  building  a  tool  a  tool  for  dehning  and 
specifying  new  combinators  that  will  produce  the  statement  of  a  theorem  of  event  logic  that 
we  can  export  to  NuPrl  in  order  to  justify  the  new  combinator. 

Another  example  of  a  programming  pattern  that  can  be  expressed  as  a  combinator  in 
is  the  gathering  of  responses  (or  other  events)  until  a  quorum  or  other  threshold  is  attained. 
By  this  we  mean  that  after  an  initiating  event  in  some  class  A,  we  accumulate  responses  in 
class  B  until  some  function  of  the  accumulated  responses  crosses  a  given  threshold.  This 
pattern  is  used,  for  example,  in  fault-tolerant  consensus  protocols  where,  after  multi-casting 
some  message,  a  process  gathers  a  quorum  of  responses.  The  quorum  is  recognized  by 
including  enough  responses  from  different  agents. 

5  Compiling 

This  section  discussions  typechecking  programs  and  generating  code  from  them. 

5.1  Typechecking 

Each  event  class  has  an  associated  type — the  type  of  the  values  it  assigns  to  the  events  it 
recognizes.  Any  reasonable  type  system  can  be  used,  and  E"^  can  be  parameterized  by  that 
choice.  Checking  the  type  correctness  of  an  5^  program  will  reduce  to  checking  the  correct 
typing  of  certain  expressions  in  the  chosen  type  system. 

So  that  we  may  use  NuPrl  for  correctness  proofs,  we  require  that  E^  programs  be  straight¬ 
forwardly  interpretable  in  NuPrl.  Thus,  the  type  system  chosen  should  either  be  NuPrl  itself 
or  easily  interpretable  in  NuPrl. ^  It  could,  for  example,  be  a  subset  of  the  type  system  in 
some  functional  programming  language  such  as  or  a  subset  of  another  higher-type  logic 
such  as  PVS. 

^The  disadvantage  of  using  the  full  type  system  of  NuPrl  is  that  type  checking  is  not  decidable.  The 
same  is  true  of  some  other  powerful  type  systems  such  as  PVS. 
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That  decision  will  be  pragmatic. 

Whatever  choice  is  made,  checking  programs  for  type  correctness  will  require: 

•  implementing  an  algorithm  that  reduces  type  checking  problems  for  to  type  check¬ 
ing  problems  in  the  chosen  type  system  for  values; 

•  reinterpreting  any  error  messages  from  that  type  checker  in  terms  that  the  E"^  pro¬ 
grammer  will  understand. 

5.2  Code  generation 

For  any  programmable  class  dehned  in  E"^,  the  computations  that  recognize  events  and 
assign  values  to  them  depend,  ultimately,  on  recognizing  hnitely  many  kinds  of  basic  events 
and  storing  hnitely  many  values  derived  from  these  basic  events.  The  propagation  rules  can 
be  implemented  by  sending  messages  and  scheduling  internal  events  after  timeouts.  Thus, 
there  is  a  compilation  algorithm  that  reduces  any  E"^  program  to  a  set  of  these  basic  actions. 

A  code  generator  for  E"^  will  have  two  key  modules:  one  unwinds  E"^  dehnitions  into 
their  basic  actions  and  the  other  implements  an  evaluator  for  terms  in  the  system  of  value 
types  used  for  E*.  (Terms  in  that  language  will  express  tests  used  in  conditional  execution, 
the  content  of  messages  to  be  sent,  etc.) 

In  the  SCorES  project  [8]  we  prototyped  a  code  generator  that  translates  message  au¬ 
tomata  into  Java.  It  implements  the  basic  communication  primitive  of  message  automata — 
reliable,  FIFO  communication  on  a  named  link — by  sockets.  So  nodes  send  messages  when¬ 
ever  they  choose,  and  recipients  not  ready  to  process  the  messages  they  receive  must  queue 
them.  In  many  applications  it  is  desirable  to  institute  a  form  of  how  control  whereby  senders 
queue  outgoing  messages  until  recipients  indicate  that  they  are  prepared  to  receive  them. 
Compiler  pragmas  should  give  users  control  over  such  global  optimization  decisions  we  will 
provide  a  menu  of  such  standard  design  options. 

6  Results  and  Discussion 

6.1  Phase  I 

In  Phase  I  we  have  dehned  a  systematic  method  for  using  event  logic  to  develop  distributed 
protocols  at  a  high  level  of  abstraction  and  the  key  elements  of  the  tool  suite.  Elan,  that 
support  it.  In  particular,  we  have  developed  a  detailed  outline  of  E*,  a  language  for  “event 
logic  programming.”  programs  are  abstract,  but  can  be  directly  compiled  into  code. 
Because  is  abstract  it  is  feasible,  we  believe,  to  verify  formally  that  an  E"^  program 
meets  high  level  requirements  stated  in  event  logic.  We  have  also  added  signihcant  support 
to  the  NuPrl  theorem  prover  for  carrying  out  those  proofs  (congruence  closure  techniques). 
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The  most  significant  theoretical  result  of  Phase  I  is  our  dehnition  of  the  concept  of 
programmable  classes  and  the  formal  proof  that  programmable  classes  are  closed  under  the 
combinator 

let  X  = 

The  proof  of  this  theorem  is  constructive,  so  it  allows  us  to  automatically  construct  a  “pro¬ 
gram”  for  class  X  from  programs  for  classes  A, . . . ,  B,C, . . . ,  D.  A  program  in  this  sense 

is 

•  A  list,  [i,j, . . .  ],  of  locations  at  which  events  in  X  may  occur. 

•  For  each  location  i,  a  list  [ki,  k2,  ■  ■  ■]  of  kinds  at  location  i  that  events  in  class  X  may 
have. 

•  A  tuple  (si  :  tyi  initially  xi,  S2  :  ty2  initially  0:2, ... )  of  typed  state  variables  with 
initial  values. 

•  For  each  location  i  and  each  k  in  the  list  of  kinds  for  that  location,  a  list  of  functions 
that  dehne  how  the  next  value  of  each  state  variable  is  computed  from  the  current 
values  of  the  state  variables  and  the  value  v  of  the  event  of  kind  k. 

•  For  each  location  i  and  each  k  in  the  list  of  kinds  for  that  location,  a  “test”  function  of 
the  current  state  variables  and  the  value  v  of  the  event,  that  returns  a  disjoint  union 
of  either  the  value  assigned  to  the  event  by  class  X  or  else  an  indication  that  the  event 
is  not  in  class  X. 

We  have  built  a  prototype  parser  and  compiler  for  that  uses  this  constructive  com¬ 
pilation  result.  For  example,  the  following  program 

let  ;  (A,B)  =  f(B,AO  where  f  (b,none)=none 

f (b,a)=pair(a,b) 
end 

let  11  =  [a  b  xl] 
let  12  =  [be  xl] 
let  kl  =  rev  11  fwd 
let  k2  =  rev  12  fwd 
kl :  int 
k2:  (int, int) 
kl;kl  =>  k2 

dehnes  a  simple  version  of  the  combinator  discussed  is  section  4.8.  It  defines  named 

links  between  locations  a,  b,  and  e,  and  kinds  kl  and  k2,  that  are  receives  on  these  links. 
The  program  declares  that  the  value  of  a  message  of  kind  kl  is  an  integer  and  that  messages 
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of  kind  k2  will  be  pairs  of  integers.  Finally,  it  asserts  the  propagation  rule  that  events  of 
class  kl;kl  will  send  their  value  to  cause  an  event  of  kind  k2. 

To  accomplish  this  propagation,  we  must  build  a  program  to  recognize  events  of  class 
kl;kl  and  compute  their  value.  The  prototype  compiler  provides  the  following  program  for 
this  class 

at  location  "b" : 

state  is  [s:int+top  initially  ff] 

[when  kind  =  rcv(link  "xl"  from  "a"  to  "b","xl") 
update  state  with: 

[s  :=  ini  val] 

test  is  case  s  of  ini (a)  =>  <a,val>  |  inr(a)  =>  ff] 

This  program  says  that  events  of  class  kl  ;kl  can  only  occur  at  location  "b"  (the  destination 
of  link  11).  Only  one  state  variable,  s,  of  type  int  +  top  is  needed.  It  is  initially  set  to 
ff ,  which  is  a  value  on  the  right  side  of  the  disjoint  union  (this  is  because  ff ,  the  “false”  of 
Nuprl’s  boolean  type,  is  dehned  by  f  f  =  inr  Ax  and  Ax  is  in  the  “don’t  care”  type  top).  The 
kind  kl  has  been  replaced  by  its  full  description  rcv(link  "xl"  from  "a"  to  "b" ,  "xl"), 
and  this  is  the  only  kind  that  an  event  in  class  kl  ;kl  may  have. 

The  compiled  program  says  that  when  an  event  of  kind  kl  occurs  we  update  the  state 
variable  s  to  ini  val,  where  val  is  the  value  of  the  event,  thus  “remembering”  that  value. 

Finally,  the  test  function,  case  s  of  inl(a)  =>  <a,val>  |  inr(a)  =>  ff,  says  that 
an  event  of  kind  kl  is  an  event  in  class  kl;kl  if  and  only  if  the  state  variable  s  has  the 
form  ini  (a)  for  some  a,  and  if  so,  the  value  assigned  to  the  event  by  class  kl  ;kl  is  the  pair 
<a,val>.  This  is  the  pair  of  the  remembered  value  and  current  value. 

6.1.1  Example  compilation 

A  more  complete  example  program  is  shown  in  hgure  1.  For  this  example,  our  prototype 
compiler  produces  the  “basic”  program  shown  in  hgure  2. 

The  basic  program  is  divided  into  instructions  at  each  location.  These  instructions  hrst 
declare  the  kinds  that  occur  at  that  location  together  with  the  type  of  their  values.  Then 
the  state  variables  needed  at  that  location  are  declared  with  their  type  and  initial  value. 

Each  kind  of  event  is  then  listed  with  its  affect  on  the  state  and  messages  it  must  prop¬ 
agate. 

Note  that  in  this  example,  at  location  "b",  an  event  of  kind  kl  will  always  be  in  the 
basic  class  kl,  and  it  will  be  in  the  dehned  class  kl;kl  if  a  previous  event  of  kind  kl  has 
occurred.  Thus  the  two  propagation  rules  kl  =>  k2  and  kl;kl  =>  k3  require  that  events 
of  kind  kl  send,  depending  on  the  state,  either  one  or  two  messages,  with  appropriate  tags. 
This  behavior  is  evident  in  the  sends  listed  for  kl,  which  is  rcv(link  "xl"  from  "a"  to 
"b" , "input"). 
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let  ;(A,B)  =  f(B,A’)  where  f (b,none)=none 

f (b,a)=pair(a,b) 
end 

let  count  (A)  =  c(A,selfO  where  c  (a, none)  =  0 

c(a,n)  =  n+1 

end 

let  11  =  [a  b  xl] 

let  12  =  [be  xl] 

let  13  =  [c  b  xl] 

let  kl  =  rev  11  input 

let  k2  =  rev  12  fwd 

let  k3  =  rev  12  fwdd 

let  k4  =  rev  13  ack 

kl :  int 

k2 :  int 

k3:  (int, int) 

k4:  int 

kl  =>  k2 

kl;kl  =>  k3 

count (k2)  =>  k4 

Figure  1:  Example  program. 
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at  location  "b" : 

kinds  are  [rev (link  "xl"  from  "a"  to  "b" , "input") : int ; 

revdink  "xl"  from  "c"  to  "b" ,  "ack")  :  int] 
state  is  [s:int+top  initially  ff] 

[when  kind  =  revdink  "xl"  from  "a"  to  "b",  "input") 
update  state  with: 

[s  :=  ini  val] 
and 

[send  [<val:int,  "fwd">/ 

case  s  of  ini (a)  =>  [<a,  val> : (int , int) ,  "fwdd"]  | 
inr(a)  =>  []  ] 

on  link  "xl"  from  "b"  to  "c"]]; 
at  location  "c": 

kinds  are  [revdink  "xl"  from  "b"  to  "c" ,  "fwd")  :  int ; 

revdink  "xl"  from  "b"  to  "c" ,  "fwdd")  :  (int , int)] 
state  is  [sl:int+top  initially  ff] 

[when  kind  =  revdink  "xl"  from  "b"  to  "c","fwd") 
update  state  with: 

[si  :=  case  si  of  inl(n)  =>  ini  (n+1)  |  inr(n)  =>  ini  0]] 
and 

[send  case  si  of  inl(n)  =>  [<n+l:int,  "ack">]  | 
inr(a)  =>  [<0:int,  "ack">] 
on  link  "xl"  from  "c"  to  "b"]]; 


Figure  2:  Basic  program  for  example  in  figure  1 
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To  complete  the  code  generation  for  this  program  we  must  generate  code  in  the  target 
language  that  implements  these  instructions.  This  will  involve  setting  up  event  handlers  for 
the  kinds  given  by  the  program  that  invoke  the  appropriate  update  methods  and  send  the 
listed  message  (or  messages). 

6.2  Phase  II 

Phase  I  research  has  provided  a  solid  basis  for  creating  a  prototype  of  the  Elan  tool  suite. 
Elan  can  be  developed  in  stages,  beginning  with  a  front  end  and  code  generator  for 
viable  as  a  stand-alone  product.  The  most  straightforward  target  for  code  generation  would 
be  a  functional  programming  language,  such  as  Microsoft’s  and  Microsoft  Research  has 
expressed  interest  in  that  possibility. 

We  will  also  use  in  a  project  with  Cornell  University,  funded  by  Air  Force  Research 
Lab,  Rome,  NY,  that  will  develop  verihed  fault-tolerant  distributed  consensus  algorithms 
and  generate  correct-by-construction  code  from  them.  In  addition  to  validating  our  methods, 
this  work  will  help  to  develop  additional  support  for  formal  verihcation. 
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